Sharing DXL scripts among DOORS users?

What is the easiest way to share DXL scripts among DOORS users?

I'm looking for an alternative to mailing everyone a file and telling them to put it in "C:\Program Files\Telelogic\DOORS_8.1\lib\dxl\addins\user", because it is too inefficient & hard to easily update.

Now I know my current & prior companies have had a "Company" menu, where there is a menu named after the company that contains our own company-specific scripts. I know these files are on a central server. So obviously using this would be easiest. However I am not yet sure I'll get permission to use this.

So the question is how is such a company-specific menu configured, and is there something I can have a subset of DOORS users do to mimic this so that this subset of users can have a common, server-based area for shared scripts?

Regards, Strathglass.
strathglass - Fri Jun 12 09:00:08 EDT 2009

Re: Sharing DXL scripts among DOORS users?
llandale - Fri Jun 12 11:16:52 EDT 2009

To share scripts you'll need to [1] Copy each file to each local computer [2] have a single shared server somewhere all your users can access [3] Have a finite set of shared servers such that all users can get at least one of them.

[1a] You can email the file and instruct on its placement.
[1b] On the old Telelogic forums someone posted a scheme where he stored the config controlled versions on a server. Each DXL had a function that would first query the server for updates, and auto-download any updated DXL to the local client.

[2] and [3] are basically the same except you need a whole lot more management for 3, including procedures for telling users how to find out which of the servers they can and should use.

[2a] You can use the 'addins' method where the scripts are structured in a suitable hierarchy on the server. See DXL manual section 'The DXL Library and Addins menus', and postings for help on that. This method requires updating ones registry, or creating a new doors.exe icon that has the "-a" and "-J" command line switches.
[2b] You can store the DXL themselves on a server and then post skeleton DXL files for each user to put in her /User folder. These skeleton files would have minimal structure and #include the actual DXL. This lets you easily manage versions and only have to publish the skeletons once. You can keep the Skeletons also on the server and instruct users how to copy them all once to their clients.

// ReportViews-s.dxl - Make Report of View in the Module
/* ReportViews.dxl reports views in the current module.
Output should be copied from the DXL output pane and pasted into Notepad
*/
#include <\\MyServer\\MyDxl\\MyModuleDxl\\ReportViews.dxl>
// end file ReportViews-s.dxl

 


-Louie

 

Re: Sharing DXL scripts among DOORS users?
strathglass - Fri Jun 12 14:34:22 EDT 2009

llandale - Fri Jun 12 11:16:52 EDT 2009

To share scripts you'll need to [1] Copy each file to each local computer [2] have a single shared server somewhere all your users can access [3] Have a finite set of shared servers such that all users can get at least one of them.

[1a] You can email the file and instruct on its placement.
[1b] On the old Telelogic forums someone posted a scheme where he stored the config controlled versions on a server. Each DXL had a function that would first query the server for updates, and auto-download any updated DXL to the local client.

[2] and [3] are basically the same except you need a whole lot more management for 3, including procedures for telling users how to find out which of the servers they can and should use.

[2a] You can use the 'addins' method where the scripts are structured in a suitable hierarchy on the server. See DXL manual section 'The DXL Library and Addins menus', and postings for help on that. This method requires updating ones registry, or creating a new doors.exe icon that has the "-a" and "-J" command line switches.
[2b] You can store the DXL themselves on a server and then post skeleton DXL files for each user to put in her /User folder. These skeleton files would have minimal structure and #include the actual DXL. This lets you easily manage versions and only have to publish the skeletons once. You can keep the Skeletons also on the server and instruct users how to copy them all once to their clients.

// ReportViews-s.dxl - Make Report of View in the Module
/* ReportViews.dxl reports views in the current module.
Output should be copied from the DXL output pane and pasted into Notepad
*/
#include <\\MyServer\\MyDxl\\MyModuleDxl\\ReportViews.dxl>
// end file ReportViews-s.dxl

 


-Louie

 

Thanks Louie.
I had found the 'The DXL Library and Addins menus' info, but by itself it didn't help.
What I needed to know that you identified was the -a and -J switches.
You've also provided good ideas on a variety of approaches to this problem.

However the manual doesn't clarify the difference between -J and -a: what is a project DXL addin directory vs. a regular addin directory? (I'm going to do some experiments now, so maybe it will become obvious.)

Regards, Strathglass.

STILL Need some more help please!
strathglass - Fri Jun 12 14:57:29 EDT 2009

strathglass - Fri Jun 12 14:34:22 EDT 2009
Thanks Louie.
I had found the 'The DXL Library and Addins menus' info, but by itself it didn't help.
What I needed to know that you identified was the -a and -J switches.
You've also provided good ideas on a variety of approaches to this problem.

However the manual doesn't clarify the difference between -J and -a: what is a project DXL addin directory vs. a regular addin directory? (I'm going to do some experiments now, so maybe it will become obvious.)

Regards, Strathglass.

OK, I tried creating a new DOORS shortcut, where the TARGET line reads exactly as follows:
"C:\Program Files\Telelogic\DOORS_8.1\bin\doors.exe" -a \\dserver\dat\dxladdins

The above dxladdins folder has 3 items: a subfolder syedxl, and files addins.hlp and addins.idx (the latter has one line: "syedxl S _ SYE").

The syedxl subfolder has a bunch of DXL scripts, and a syedxl.hlp file and a syedxl.idx file (the latter listing all the DXL scripts, without suffix, followed by a single letter, underscore, and script description, all separated by one or more spaces).

But when I run this shortcut, I still see the standard User menu on modules (from the standard C: drive location), nothing from my syedxl folder anywhere.
Same is true if I use -J <dir> instead of -a <dir>, and also true if I use both -J <dir> -a <dir>.

Can anyone advise what I might be doing wrong?

Thanks, Strathglass.

Re: STILL Need some more help please!
kbmurphy - Fri Jun 12 16:05:40 EDT 2009

strathglass - Fri Jun 12 14:57:29 EDT 2009
OK, I tried creating a new DOORS shortcut, where the TARGET line reads exactly as follows:
"C:\Program Files\Telelogic\DOORS_8.1\bin\doors.exe" -a \\dserver\dat\dxladdins

The above dxladdins folder has 3 items: a subfolder syedxl, and files addins.hlp and addins.idx (the latter has one line: "syedxl S _ SYE").

The syedxl subfolder has a bunch of DXL scripts, and a syedxl.hlp file and a syedxl.idx file (the latter listing all the DXL scripts, without suffix, followed by a single letter, underscore, and script description, all separated by one or more spaces).

But when I run this shortcut, I still see the standard User menu on modules (from the standard C: drive location), nothing from my syedxl folder anywhere.
Same is true if I use -J <dir> instead of -a <dir>, and also true if I use both -J <dir> -a <dir>.

Can anyone advise what I might be doing wrong?

Thanks, Strathglass.

Silly strath! You think you can read a few pointers in the reference manuals and figure this stuff out? Like the manuals are written well and supposed to be useful or something!

Anyhow, the difference between -a and -J is simply where the menu add-in appears. -J says, "Appear in the DOORS Explorer" (-J has NOTHING to do with projects), and -a says, "Appear in each module."

Also, your DXL must be formatted with the first line being a // comment and the next lines being a multi-line comment like so:

//mydxl.dxl
/*
Optional description
*/

What I would say to do to troubleshoot your problem is to:

1. Map a drive letter to your addin location (don't use \\server\path)
2. Change any \ to / so that it looks like -a c:/addins/
3. Get the addins under c:\program files and copy them to your network location...you know that the user menu works already.
4. Copy one of your DXL files, formatted as I show above, to the User menu on your C:\ drive.

There are lots of areas where you could have done something wrong, so you will likely have to spend a lot of time to figure this one out. I've spent hours of my life configuring DOORS shortcuts to work properly.

Re: STILL Need some more help please!
llandale - Fri Jun 12 16:35:27 EDT 2009

strathglass - Fri Jun 12 14:57:29 EDT 2009
OK, I tried creating a new DOORS shortcut, where the TARGET line reads exactly as follows:
"C:\Program Files\Telelogic\DOORS_8.1\bin\doors.exe" -a \\dserver\dat\dxladdins

The above dxladdins folder has 3 items: a subfolder syedxl, and files addins.hlp and addins.idx (the latter has one line: "syedxl S _ SYE").

The syedxl subfolder has a bunch of DXL scripts, and a syedxl.hlp file and a syedxl.idx file (the latter listing all the DXL scripts, without suffix, followed by a single letter, underscore, and script description, all separated by one or more spaces).

But when I run this shortcut, I still see the standard User menu on modules (from the standard C: drive location), nothing from my syedxl folder anywhere.
Same is true if I use -J <dir> instead of -a <dir>, and also true if I use both -J <dir> -a <dir>.

Can anyone advise what I might be doing wrong?

Thanks, Strathglass.

The *.idx and *.hlp files MUST have the exact same name as the folder in which they are housed, in your case you need to rename them: 'dxladdins.idx' and 'dxladdins.hlp'. These two files must exist but can be completely empty and you'll still get acceptable menus displayed.

Yes, the DXL files themselves require a single comment line and a comment block 'near the top' of the file. Not sure exactly what 'near the top' means, but mine are routinely 'at the top'.

Yes, the -a files appear in Module menus and the -J files appear in the module explorer. It makes sense that the 'Module' scripts presume a current module, and the 'Project' scripts do not. I've got two piles of scripts; the 'Project-Scripts' menu appears in the Explorer and the 'Module-Scripts' and also the 'Project-Scripts' menus appear in formal modules. I should probably rename it 'Explorer-Scripts' or 'Folder-Scripts'.

Only .dxl files will appear in menus. Non-.dxl files in the folders will be ignored.

The 'User' menu, sadly, only appears in module menues.

For 'addins' you can 'browse' for the DXL using Tools menu >DXL Library.. from a module. The top pane contains the blurb from the *.idx file (if its a folder) or the comment line (if its a *.dxl), and the bottom blurb contains the info from the *.hlp (if its a folder) or the comment block (if its a *.dxl).

The *.idx files may refer to DXL files in that folder. If so, the menu contains the blurb on the right of the line. If there's a DXL file not in the *.idx, its name is listed in the Menu. If the *.idx refers to a dxl file that doesn't exist, nothing is displayed for it.

Every time you open a formal module, DOORS reaches back to the Server, opens up all the folders, *.idx, *.hlp, and *.dxl files to build your menu for that module; it does NOT remember between modules. This means that if the server is 'far away' on the network you will experience significant delays opening each and every module (visibly).

-Louie

Re: Sharing DXL scripts among DOORS users?
ozgury - Mon Jun 15 04:49:28 EDT 2009

I had the same problem.
My solution is simple.
1. Put the dxl files to a network drive that everyone can read.
2. Modify the "startup.dxl" file so that when a user logs in, all the dxl files on the network are copied to local.
You can organize your files (as others explained) into directories. All the directory structure is copied. And you will have the menu entries just like the directory struture.
All a user has to do is copy the modified "startup.dxl" file into "lib/dxl" directory. By this method I can change the files on the net, and I know that everybody has the most recent file. We use this method for sharing templates and some other numbering scripts.
It works fine so far.
You can modify this method by writing different startup files for different groups of people.

Regards
Özgür

Re: Sharing DXL scripts among DOORS users?
dpechacek - Mon Jun 15 13:23:06 EDT 2009

I have a script that runs when DOORS starts up that adds and deletes files based off an identical structure on network drives. Refreshes all a users tools for them with every login. Saves me from having to push files out to people. And the file that goes on their machine is still just a DXL file with an include. The includes are all encrypted and elsewhere on the network.

AAI Services, Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com

Re: Sharing DXL scripts among DOORS users?
strathglass - Thu Jun 18 11:06:17 EDT 2009

dpechacek - Mon Jun 15 13:23:06 EDT 2009
I have a script that runs when DOORS starts up that adds and deletes files based off an identical structure on network drives. Refreshes all a users tools for them with every login. Saves me from having to push files out to people. And the file that goes on their machine is still just a DXL file with an include. The includes are all encrypted and elsewhere on the network.

AAI Services, Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com

Thanks to kbmurphy and all for your excellent input - it is much appreciated.

However it was Louie's advice that was key: I simply had to fix the .idx and .hlp file names for the two I had at the lowest level (forgot to name those to match the directory name; had only done that for the pair one level up).

Once I did that, I was on my way.

One minor strange point: I did learn if you add the "-a <my_script_dir>" option when starting DOORS, I would lose the company-default user menu for some reason (even though that was appearing NOT due to the use of any command startup option). So I had to do "-a <company_script_dir>;<my_script_dir>" to get everything back to normal (i.e. to continue to see the company's menu and also see my own new customized menu) (I knew the directory where the company scripts were held, fortunately!).

Regards, Strathglass

Re: Sharing DXL scripts among DOORS users?
llandale - Thu Jun 18 14:18:37 EDT 2009

strathglass - Thu Jun 18 11:06:17 EDT 2009
Thanks to kbmurphy and all for your excellent input - it is much appreciated.

However it was Louie's advice that was key: I simply had to fix the .idx and .hlp file names for the two I had at the lowest level (forgot to name those to match the directory name; had only done that for the pair one level up).

Once I did that, I was on my way.

One minor strange point: I did learn if you add the "-a <my_script_dir>" option when starting DOORS, I would lose the company-default user menu for some reason (even though that was appearing NOT due to the use of any command startup option). So I had to do "-a <company_script_dir>;<my_script_dir>" to get everything back to normal (i.e. to continue to see the company's menu and also see my own new customized menu) (I knew the directory where the company scripts were held, fortunately!).

Regards, Strathglass

Yes, the -a command line switch changes the 'addins' environment variable, which is in your Registry; it does not append to it.